chore: Adds feature metrics for collection prefs and button group #3180
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3180 +/- ##
========================================
Coverage 96.41% 96.42%
========================================
Files 784 784
Lines 22168 22179 +11
Branches 7206 7610 +404
========================================
+ Hits 21373 21385 +12
+ Misses 788 787 -1
Partials 7 7 ☔ View full report in Codecov by Sentry. |
| expect(useBaseComponent).toHaveBeenCalledWith('ButtonGroup', { | ||
| props: { | ||
| variant: 'icon', | ||
| dropdownExpandToViewport: undefined, |
There was a problem hiding this comment.
should this be false instead? Not sure how the metrics handle undefined values here
There was a problem hiding this comment.
Metrics use JSON.stringify. When you serialise undefined, it disappears completely, same as this key did not exist before.
Explicit casting is recommended
There was a problem hiding this comment.
Yeah, I was thinking about that too, but decided not touch it just yet. I think it would be nice to align within the team if we want to cast or not and how do we want to treat properties that have defaults: should we pass the default value or the missing one, as it directly affects the actual metrics we gather.
There was a problem hiding this comment.
In all other cases, we track resolved values after defaulting.
For dropdownExpandToViewport there is an implicit default false which we should be tracking.
There was a problem hiding this comment.
After the team discussion we settled on passing the default property values to metrics. I added a new commit that implements that for dropdownExpandToViewport.
pan-kot
force-pushed
the
chore-add-feature-metrics
branch
from
11d5861 to
d931b64
Compare
pan-kot
force-pushed
the
chore-add-feature-metrics
branch
from
d931b64 to
eae6af7
Compare
| jest.mock('@cloudscape-design/component-toolkit/internal', () => ({ | ||
| ...jest.requireActual('@cloudscape-design/component-toolkit/internal'), | ||
| warnOnce: jest.fn(), | ||
| })); | ||
|
|
||
| afterEach(() => { | ||
| (warnOnce as jest.Mock).mockReset(); | ||
| (useBaseComponent as jest.Mock).mockReset(); |
There was a problem hiding this comment.
Mocking React hooks is an anti pattern, it caused problems in the past, and we do not recommend any teams to do, so we also should not do it in our code.
If you want to test this, do it differently, not via mocking the hook
There was a problem hiding this comment.
I replaced it with a spy instead so that the original hook is called.
There was a problem hiding this comment.
The original hook is not called.
Try adding a logging around this line, but it is never printed in your test
There was a problem hiding this comment.
Oh, indeed - apologies! I forgot to remove the old mock after my testing: 9ba4505
I did test it by adding the logs to the original hook, so now it is certainly called for each test case.
Description
Related links, issue #, if available: n/a
How has this been tested?
Review checklist
The following items are to be evaluated by the author(s) and the reviewer(s).
Correctness
CONTRIBUTING.md.CONTRIBUTING.md.Security
checkSafeUrlfunction.Testing
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.